Method, apparatus, and system for speculative abort control mechanisms

ABSTRACT

An apparatus and method is described herein for providing robust speculative code section abort control mechanisms. Hardware is able to track speculative code region abort events, conditions, and/or scenarios, such as an explicit abort instruction, a data conflict, a speculative timer expiration, a disallowed instruction attribute or type, etc. And hardware, firmware, software, or a combination thereof makes an abort determination based on the tracked abort events. As an example, hardware may make an initial abort determination based on one or more predefined events or choose to pass the event information up to a firmware or software handler to make such an abort determination. Upon determining an abort of a speculative code region is to be performed, hardware, firmware, software, or a combination thereof performs the abort, which may include following a fallback path specified by hardware or software. And to enable testing of such a fallback path, in one implementation, hardware provides software a mechanism to always abort speculative code regions.

CROSS-REFERENCE TO RELATED APPLICATION

This is a continuation application of U.S. patent application Ser. No.13/997,248, filed Jun. 22, 2013, which is a U.S. National Phaseapplication under 35 U.S.C. §371 of International Application No.PCT/US2012/023597, filed Feb. 2, 2012.

FIELD

This disclosure pertains to the field of integrated circuits and, inparticular, to speculative execution, transactional execution, and abortcontrol thereof.

BACKGROUND

Advances in semi-conductor processing and logic design have permitted anincrease in the amount of logic that may be present on integratedcircuit devices. As a result, computer system configurations haveevolved from a single or multiple integrated circuits in a system tomultiple cores and multiple logical processors present on individualintegrated circuits. A processor or integrated circuit typicallycomprises a single processor die, where the processor die may includeany number of cores or logical processors.

The ever increasing number of cores and logical processors on integratedcircuits enables more software threads to be concurrently executed.However, the increase in the number of software threads that may beexecuted simultaneously have created problems with synchronizing datashared among the software threads. One common solution to accessingshared data in multiple core or multiple logical processor systemscomprises the use of locks to guarantee mutual exclusion across multipleaccesses to shared data. However, the ever increasing ability to executemultiple software threads potentially results in false contention and aserialization of execution.

For example, consider a hash table holding shared data. With a locksystem, a programmer may lock the entire hash table, allowing one threadto access the entire hash table. However, throughput and performance ofother threads is potentially adversely affected, as they are unable toaccess any entries in the hash table, until the lock is released.Alternatively, each entry in the hash table may be locked. Either way,after extrapolating this simple example into a large scalable program,it is apparent that the complexity of lock contention, serialization,fine-grain synchronization, and deadlock avoidance become extremelycumbersome burdens for programmers.

Another recent data synchronization technique includes the use oftransactional memory (TM). Often transactional execution includesexecuting a grouping of a plurality of micro-operations, operations, orinstructions atomically. In the example above, both threads executewithin the hash table, and their memory accesses are monitored/tracked.If both threads access/alter the same entry, conflict resolution may beperformed to ensure data validity. One type of transactional executionincludes Software Transactional Memory (STM), where tracking of memoryaccesses, conflict resolution, abort tasks, and other transactionaltasks are performed in software, often without the support of hardware.Another type of transactional execution includes a HardwareTransactional Memory (HTM) System, where hardware is included to supportaccess tracking, conflict resolution, and other transactional tasks.

A technique similar to transactional memory includes hardware lockelision (HLE), where a locked critical section is executed tentativelywithout the locks. And if the execution is successful (i.e. noconflicts), then the result are made globally visible. In other words,the critical section is executed like a transaction with the lockinstructions from the critical section being elided, instead ofexecuting an atomically defined transaction. As a result, in the exampleabove, instead of replacing the hash table execution with a transaction,the critical section defined by the lock instructions are executedtentatively. Multiple threads similarly execute within the hash table,and their accesses are monitored/tracked. If both threads access/alterthe same entry, conflict resolution may be performed to ensure datavalidity. But if no conflicts are detected, the updates to the hashtable are atomically committed.

As can be seen, transactional execution and lock elision have thepotential to provide better performance among multiple threads. However,HLE and TM are relatively new fields of study with regards tomicroprocessors. And as a result, HLE and TM implementations inprocessors have not bee fully explored or detailed.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not intendedto be limited by the figures of the accompanying drawings.

FIG. 1 illustrates an embodiment of a logical representation of a systemincluding processor having multiple processing elements (2 cores and 4thread slots).

FIG. 2 illustrates an embodiment of a multiprocessor system.

FIG. 3 illustrates another embodiment of a multiprocessor system.

FIG. 4 illustrates another embodiment of a multiprocessor system.

FIG. 5 illustrates an embodiment of a logical representation of modulesfor a processor to provide abort control mechanisms.

FIG. 6 illustrates an embodiment of a logical representation of modulesfor an abort control mechanism.

FIG. 7 illustrates an embodiment of a flow diagram for a method ofproviding an abort control mechanism.

FIG. 8 illustrates another embodiment of a flow diagram for a method ofproviding an abort control mechanism.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth,such as examples of specific types of specific processor configurations,specific hardware structures, specific architectural and microarchitectural details, specific register configurations, specific lockinstructions, specific types of hardware monitors/tracking, specificdata buffering techniques, specific critical section executiontechniques, etc. in order to provide a thorough understanding of thepresent invention. It will be apparent, however, to one skilled in theart that these specific details need not be employed to practice thepresent invention. In other instances, well known components or methods,such as specific and alternative processor architectures, specific logiccircuits/code for described algorithms, specific cache coherencydetails, specific lock instruction and critical section identificationtechniques, specific compiler makeup and operation, specifictransactional memory structures, specific/detailed instructionimplementation and Instruction Set Architecture definition, and otherspecific operational details of processors haven't been described indetail in order to avoid unnecessarily obscuring the present invention.

Although the following embodiments are described with reference to aprocessor, other embodiments are applicable to other types of integratedcircuits and logic devices. Similar techniques and teachings ofembodiments described herein may be applied to other types of circuitsor semiconductor devices that can benefit from higher throughput andperformance. For example, the disclosed embodiments are not limited tocomputer systems. And may be also used in other devices, such ashandheld devices, systems on a chip (SOC), and embedded applications.Some examples of handheld devices include cellular phones, Internetprotocol devices, digital cameras, personal digital assistants (PDAs),and handheld PCs. Embedded applications include a microcontroller, adigital signal processor (DSP), a system on a chip, network computers(NetPC), set-top boxes, network hubs, wide area network (WAN) switches,or any other system that can perform the functions and operations taughtbelow.

The method and apparatus described herein are for supporting lockelision and transactional memory. Specifically, lock elision (LE) andtransactional memory (TM) are discussed with regard to transactionalexecution with a microprocessor, such as processor 100. Yet, theapparatus' and methods described herein are not so limited, as they maybe implemented in conjunction with alternative processor architectures,as well as any device including multiple processing elements. Forexample, LE and/or RTM may be implemented in other types of integratedcircuits and logic devices. Or it may be utilized in small form-factordevices, handheld devices, SOCs, or embedded applications, as discussedabove.

Referring to FIG. 1, an embodiment of a processor including multiplecores is illustrated. Processor 100 includes any processor or processingdevice, such as a microprocessor, an embedded processor, a digitalsignal processor (DSP), a network processor, a handheld processor, anapplication processor, a co-processor, or other device to execute code.Processor 100, in one embodiment, includes at least two cores—core 101and 102, which may include asymmetric cores or symmetric cores (theillustrated embodiment). However, processor 100 may include any numberof processing elements that may be symmetric or asymmetric.

In one embodiment, a processing element refers to hardware or logic tosupport a software thread. Examples of hardware processing elementsinclude: a thread unit, a thread slot, a thread, a process unit, acontext, a context unit, a logical processor, a hardware thread, a core,and/or any other element, which is capable of holding a state for aprocessor, such as an execution state or architectural state. In otherwords, a processing element, in one embodiment, refers to any hardwarecapable of being independently associated with code, such as a softwarethread, operating system, application, or other code. A physicalprocessor typically refers to an integrated circuit, which potentiallyincludes any number of other processing elements, such as cores orhardware threads.

A core often refers to logic located on an integrated circuit capable ofmaintaining an independent architectural state, wherein eachindependently maintained architectural state is associated with at leastsome dedicated execution resources. In contrast to cores, a hardwarethread typically refers to any logic located on an integrated circuitcapable of maintaining an independent architectural state, wherein theindependently maintained architectural states share access to executionresources. As can be seen, when certain resources are shared and othersare dedicated to an architectural state, the line between thenomenclature of a hardware thread and core overlaps. Yet often, a coreand a hardware thread are viewed by an operating system as individuallogical processors, where the operating system is able to individuallyschedule operations on each logical processor.

Physical processor 100, as illustrated in FIG. 1, includes two cores,core 101 and 102. Here, core 101 and 102 are considered symmetric cores,i.e. cores with the same configurations, functional units, and/or logic.In another embodiment, core 101 includes an out-of-order processor core,while core 102 includes an in-order processor core. However, cores 101and 102 may be individually selected from any type of core, such as anative core, a software managed core, a core adapted to execute a nativeInstruction Set Architecture (ISA), a core adapted to execute atranslated Instruction Set Architecture (ISA), a co-designed core, orother known core. Yet to further the discussion, the functional unitsillustrated in core 101 are described in further detail below, as theunits in core 102 operate in a similar manner.

As depicted, core 101 includes two hardware threads 101 a and 101 b,which may also be referred to as hardware thread slots 101 a and 101 b.Therefore, software entities, such as an operating system, in oneembodiment potentially view processor 100 as four separate processors,i.e. four logical processors or processing elements capable of executingfour software threads concurrently. As eluded to above, a first threadis associated with architecture state registers 101 a, a second threadis associated with architecture state registers 101 b, a third threadmay be associated with architecture state registers 102 a, and a fourththread may be associated with architecture state registers 102 b. Here,each of the architecture state registers (101 a, 101 b, 102 a, and 102b) may be referred to as processing elements, thread slots, or threadunits, as described above. As illustrated, architecture state registers101 a are replicated in architecture state registers 101 b, soindividual architecture states/contexts are capable of being stored forlogical processor 101 a and logical processor 101 b. In core 101, othersmaller resources, such as instruction pointers and renaming logic inrename allocator logic 130 may also be replicated for threads 101 a and101 b. Some resources, such as re-order buffers in reorder/retirementunit 135, ILTB 120, load/store buffers, and queues may be shared throughpartitioning. Other resources, such as general purpose internalregisters, page-table base register(s), low-level data-cache anddata-TLB 115, execution unit(s) 140, and portions of out-of-order unit135 are potentially fully shared.

Processor 100 often includes other resources, which may be fully shared,shared through partitioning, or dedicated by/to processing elements. InFIG. 1, an embodiment of a purely exemplary processor with illustrativelogical units/resources of a processor is illustrated. Note that aprocessor may include, or omit, any of these functional units, as wellas include any other known functional units, logic, or firmware notdepicted. As illustrated, core 101 includes a simplified, representativeout-of-order (OOO) processor core. But an in-order processor may beutilized in different embodiments. The OOO core includes a branch targetbuffer 120 to predict branches to be executed/taken and aninstruction-translation buffer (I-TLB) 120 to store address translationentries for instructions.

Core 101 further includes decode module 125 coupled to fetch unit 120 todecode fetched elements. Fetch logic, in one embodiment, includesindividual sequencers associated with thread slots 101 a, 101 b,respectively. Usually core 101 is associated with a first InstructionSet Architecture (ISA), which defines/specifies instructions executableon processor 100. Often machine code instructions that are part of thefirst ISA include a portion of the instruction (referred to as anopcode), which references/specifies an instruction or operation to beperformed. Decode logic 125 includes circuitry that recognizes theseinstructions from their opcodes and passes the decoded instructions onin the pipeline for processing as defined by the first ISA. For example,as discussed in more detail below decoders 125, in one embodiment,include logic designed or adapted to recognize specific instructions,such as transactional instructions or non-transactional instructions forexecution within a critical section or transactional region. As a resultof the recognition by decoders 125, the architecture or core 101 takesspecific, predefined actions to perform tasks associated with theappropriate instruction. It is important to note that any of the tasks,blocks, operations, and methods described herein may be performed inresponse to a single or multiple instructions; some of which may be newor old instructions.

In one example, allocator and renamer block 130 includes an allocator toreserve resources, such as register files to store instructionprocessing results. However, threads 101 a and 101 b are potentiallycapable of out-of-order execution, where allocator and renamer block 130also reserves other resources, such as reorder buffers to trackinstruction results. Unit 130 may also include a register renamer torename program/instruction reference registers to other registersinternal to processor 100. Reorder/retirement unit 135 includescomponents, such as the reorder buffers mentioned above, load buffers,and store buffers, to support out-of-order execution and later in-orderretirement of instructions executed out-of-order.

Scheduler and execution unit(s) block 140, in one embodiment, includes ascheduler unit to schedule instructions/operation on execution units.For example, a floating point instruction is scheduled on a port of anexecution unit that has an available floating point execution unit.Register files associated with the execution units are also included tostore information instruction processing results. Exemplary executionunits include a floating point execution unit, an integer executionunit, a jump execution unit, a load execution unit, a store executionunit, and other known execution units.

Lower level data cache and data translation buffer (D-TLB) 150 arecoupled to execution unit(s) 140. The data cache is to store recentlyused/operated on elements, such as data operands, which are potentiallyheld in memory coherency states. The D-TLB is to store recentvirtual/linear to physical address translations. As a specific example,a processor may include a page table structure to break physical memoryinto a plurality of virtual pages.

Here, cores 101 and 102 share access to higher-level or further-outcache 110, which is to cache recently fetched elements. Note thathigher-level or further-out refers to cache levels increasing or gettingfurther way from the execution unit(s). In one embodiment, higher-levelcache 110 is a last-level data cache—last cache in the memory hierarchyon processor 100—such as a second or third level data cache. However,higher level cache 110 is not so limited, as it may be associated withor include an instruction cache. A trace cache—a type of instructioncache—instead may be coupled after decoder 125 to store recently decodedinstruction traces.

In the depicted configuration, processor 100 also includes bus interfacemodule 105. Historically, controller 170, which is described in moredetail below, has been included in a computing system external toprocessor 100. In this scenario, bus interface 105 is to communicatewith devices external to processor 100, such as system memory 175, achipset (often including a memory controller hub to connect to memory175 and an I/O controller hub to connect peripheral devices), a memorycontroller hub, a northbridge, or other integrated circuit. And in thisexemplary configuration, bus 105 may include any known interconnect,such as multi-drop bus, a point-to-point interconnect, a serialinterconnect, a parallel bus, a coherent (e.g. cache coherent) bus, alayered protocol architecture, a differential bus, and a GTL bus.

Memory 175 may be dedicated to processor 100 or shared with otherdevices in a system. Common examples of types of memory 175 includedynamic random access memory (DRAM), static RAM (SRAM), non-volatilememory (NV memory), and other known storage devices. Note that device180 may include a graphic accelerator, processor or card coupled to amemory controller hub, data storage coupled to an I/O controller hub, awireless transceiver, a flash device, an audio controller, a networkcontroller, or other known device.

Note however, that in the depicted embodiment, the controller 170 isillustrated as part of processor 100. Recently, as more logic anddevices are being integrated on a single die, such as System on a Chip(SOC), each of these devices may be incorporated on processor 100. Forexample in one embodiment, memory controller hub 170 is on the samepackage and/or die with processor 100. Here, a portion of the core (anon-core portion) includes one or more controller(s) 170 for interfacingwith other devices such as memory 175 or a graphics device 180. Theconfiguration including an interconnect and/or controllers forinterfacing with such devices is often referred to as an on-core (orun-core configuration). As an example, bus interface 105 includes a ringinterconnect with a memory controller for interfacing with memory 175and a graphics controller for interfacing with graphics processor 180.Yet, in the SOC environment, even more devices, such as the networkinterface, co-processors, memory 175, graphics processor 180, and anyother known computer devices/interface may be integrated on a single dieor integrated circuit to provide small form factor with highfunctionality and low power consumption.

In one embodiment, processor 100 is capable of hardware transactionalexecution, software transactional execution, or a combination/hybridthereof. A transaction, which may also be referred to as execution of anatomic section/region of code, includes a grouping of instructions oroperations to be executed as an atomic group. For example, instructionsor operations may be used to demarcate or delimit a transaction or acritical section. In one embodiment, which is described in more detailbelow, these instructions are part of a set of instructions, such as anInstruction Set Architecture (ISA), which are recognizable by hardwareof processor 100, such as decoder(s) 125 described above. Often, theseinstructions, once compiled from a high-level language to hardwarerecognizable assembly language include operation codes (opcodes), orother portions of the instructions, that decoder(s) 125 recognize duringa decode stage. Transactional execution may be referred to herein asexplicit (transactional memory via new instructions) or implicit(speculative lock elision via eliding of lock instructions, which ispotentially based on hint versions of lock instructions).

Typically, during execution of a transaction, updates to memory are notmade globally visible until the transaction is committed. As an example,a transactional write to a location is potentially visible to a localthread; yet, in response to a read from another thread the write data isnot forwarded until the transaction including the transactional write iscommitted. While the transaction is still pending, data items/elementsloaded from and written to within a memory are tracked, as discussed inmore detail below. Once the transaction reaches a commit point, ifconflicts have not been detected for the transaction, then thetransaction is committed and updates made during the transaction aremade globally visible. However, if the transaction is invalidated duringits pendency, the transaction is aborted and potentially restartedwithout making the updates globally visible. As a result, pendency of atransaction, as used herein, refers to a transaction that has begunexecution and has not been committed or aborted (i.e. pending).

A Software Transactional Memory (STM) system often refers to performingaccess tracking, conflict resolution, or other transactional memorytasks within or at least primarily through execution of software orcode. In one embodiment, processor 100 is capable of executingtransactions utilizing hardware/logic, i.e. within a HardwareTransactional Memory (HTM) system, which is also referred to as aRestricted Transactional Memory (RTM) since it is restricted to theavailable hardware resources. Numerous specific implementation detailsexist both from an architectural and microarchitectural perspective whenimplementing an HTM; most of which are not discussed herein to avoidunnecessarily obscuring the discussion. However, some structures,resources, and implementations are disclosed for illustrative purposes.Yet, it should be noted that these structures and implementations arenot required and may be augmented and/or replaced with other structureshaving different implementation details.

Another execution technique closely related to transactional memoryincludes lock elision {often referred to as speculative lock elision(SLE) or hardware lock elision (HLE)}. In this scenario, lockinstruction pairs (lock and lock release) are augmented/replaced (eitherby a user, software, or hardware) to indicate atomic a start and an endof a critical section. And the critical section is executed in a similarmanner to a transaction (i.e. tentative results are not made globallyvisible until the end of the critical section). Note that the discussionimmediately below returns generally to transactional memory; however,the description may similarly apply to SLE, which is described in moredetail later.

As a combination, processor 100 may be capable of executing transactionsusing a hybrid approach (both hardware and software), such as within anunbounded transactional memory (UTM) system, which attempts to takeadvantage of the benefits of both STM and HTM systems. For example, anHTM is often fast and efficient for executing small transactions,because it does not rely on software to perform all of the accesstracking, conflict detection, validation, and commit for transactions.However, HTMs are usually only able to handle smaller transactions,while STMs are able to handle larger size transactions, which are oftenreferred to as unbounded sized transactions. Therefore, in oneembodiment, a UTM system utilizes hardware to execute smallertransactions and software to execute transactions that are too big forthe hardware. As can be seen from the discussion below, even whensoftware is handling transactions, hardware may be utilized to assistand accelerate the software; this hybrid approach is commonly referredto as a hardware accelerated STM, since the primary transactional memorysystem (bookkeeping, etc) resides in software but is accelerated usinghardware hooks.

Returning the discussion to FIG. 1, in one embodiment, processor 100includes monitors to detect or track accesses, and potential subsequentconflicts, associated with data items; these may be utilized in hardwaretransactional execution, lock elision, acceleration of a softwaretransactional memory system, or a combination thereof. A data item, dataobject, or data element, such as data item 201, may include data at anygranularity level, as defined by hardware, software or a combinationthereof. A non-exhaustive list of examples of data, data elements, dataitems, or references thereto, include a memory address, a data object, aclass, a field of a type of dynamic language code, a type of dynamiclanguage code, a variable, an operand, a data structure, and an indirectreference to a memory address. However, any known grouping of data maybe referred to as a data element or data item. A few of the examplesabove, such as a field of a type of dynamic language code and a type ofdynamic language code refer to data structures of dynamic language code.To illustrate, dynamic language code, such as Java™ from SunMicrosystems, Inc, is a strongly typed language. Each variable has atype that is known at compile time. The types are divided in twocategories—primitive types (boolean and numeric, e.g., int, float) andreference types (classes, interfaces and arrays). The values ofreference types are references to objects. In Java™, an object, whichconsists of fields, may be a class instance or an array. Given object aof class A it is customary to use the notation A::x to refer to thefield x of type A and a·x to the field x of object a of class A. Forexample, an expression may be couched as a·x=a·y+a·z. Here, field y andfield z are loaded to be added and the result is to be written to fieldx.

Therefore, monitoring/buffering memory accesses to data items may beperformed at any of data level granularity. For example in oneembodiment, memory accesses to data are monitored at a type level. Here,a transactional write to a field A::x and a non-transactional load offield A::y may be monitored as accesses to the same data item, i.e. typeA. In another embodiment, memory access monitoring/buffering isperformed at a field level granularity. Here, a transactional write toA::x and a non-transactional load of A::y are not monitored as accessesto the same data item, as they are references to separate fields. Note,other data structures or programming techniques may be taken intoaccount in tracking memory accesses to data items. As an example, assumethat fields x and y of object of class A (i.e. A::x and A::y) point toobjects of class B, are initialized to newly allocated objects, and arenever written to after initialization. In one embodiment, atransactional write to a field B::z of an object pointed to by A::x arenot monitored as memory access to the same data item in regards to anon-transactional load of field B::z of an object pointed to by A::y.Extrapolating from these examples, it is possible to determine thatmonitors may perform monitoring/buffering at any data granularity level.

Note these monitors, in one embodiment, are the same attributes (orincluded with) the attributes described above. Monitors may be utilizedpurely for tracking and conflict detection purposes. Or in anotherscenario, monitors double as hardware tracking and software accelerationsupport. Hardware of processor 100, in one embodiment, includes readmonitors and write monitors to track loads and stores, which aredetermined to be monitored, accordingly (i.e. track tentative accessesfrom a transaction region or critical section). Hardware read monitorsand write monitors may monitor data items at a granularity of the dataitems despite the granularity of underlying storage structures. Oralternatively, they monitor at the storage structure granularity. In oneembodiment, a data item is bounded by tracking mechanisms associated atthe granularity of the storage structures to ensure the at least theentire data item is monitored appropriately. As an illustrative example,if a data object spans 1.5 cache lines, the monitors for each of the twocache lines are set to ensure that the entire data object isappropriately tracked even though the second cache line is not full withtentative data.

In one embodiment, read and write monitors include attributes associatedwith cache locations, such as locations within lower level data cache150, to monitor loads from and stores to addresses associated with thoselocations. Here, a read attribute for a cache location of data cache 150is set upon a read event to an address associated with the cachelocation to monitor for potential conflicting writes to the sameaddress. In this case, write attributes operate in a similar manner forwrite events to monitor for potential conflicting reads and writes tothe same address. To further this example, hardware is capable ofdetecting conflicts based on snoops for reads and writes to cachelocations with read and/or write attributes set to indicate the cachelocations are monitored. Inversely, setting read and write monitors, orupdating a cache location to a buffered state, in one embodiment,results in snoops, such as read requests or read for ownership requests,which allow for conflicts with addresses monitored in other caches to bedetected.

Therefore, based on the design, different combinations of cachecoherency requests and monitored coherency states of cache lines resultin potential conflicts, such as a cache line holding a data item in ashared, read monitored state and an external snoop indicating a writerequest to the data item. Inversely, a cache line holding a data itembeing in a buffered write state and an external snoop indicating a readrequest to the data item may be considered potentially conflicting. Inone embodiment, to detect such combinations of access requests andattribute states, snoop logic is coupled to conflict detection/reportinglogic, such as monitors and/or logic for conflict detection/reporting,as well as status registers to report the conflicts.

However, any combination of conditions and scenarios may be consideredinvalidating for a transaction or critical section. Examples of factors,which may be considered for non-commit of a transaction, includesdetecting a conflict to a transactionally accessed memory location,losing monitor information, losing buffered data, losing metadataassociated with a transactionally accessed data item, and detecting another invalidating event, such as an interrupt, ring transition, or anexplicit user instruction.

In one embodiment, hardware of processor 100 is to hold transactionalupdates in a buffered manner. As stated above, transactional writes arenot made globally visible until commit of a transaction. However, alocal software thread associated with the transactional writes iscapable of accessing the transactional updates for subsequenttransactional accesses. As a first example, a separate buffer structureis provided in processor 100 to hold the buffered updates, which iscapable of providing the updates to the local thread and not to otherexternal threads.

In contrast, as another example, a cache memory (e.g. data cache 150) isutilized to buffer the updates, while providing the same transactionalor lock elision buffering functionality. Here, cache 150 is capable ofholding data items in a buffered coherency state, which may include afull new coherency state or a typical coherency state with a writemonitor set to indicate the associated line holds tentative writeinformation. In the first case, a new buffered coherency state is addedto a cache coherency protocol, such as a Modified Exclusive SharedInvalid (MESI) protocol to form a MESIB protocol. In response to localrequests for a buffered data item—data item being held in a bufferedcoherency state, cache 150 provides the data item to the localprocessing element to ensure internal transactional sequential ordering.However, in response to external access requests, a miss response isprovided to ensure the transactionally updated data item is not madeglobally visible until commit. Furthermore, when a line of cache 150 isheld in a buffered coherency state and selected for eviction, thebuffered update is not written back to higher level cache memories—thebuffered update is not to be proliferated through the memory system(i.e. not made globally visible, until after commit). Instead, thetransaction may abort or the evicted line may be stored in a speculativestructure between the data cache and the higher level cache memories,such as a victim cache. Upon commit, the buffered lines are transitionedto a modified state to make the data item globally visible. Note thesame action/responses, in another embodiment, are taken when a normalMESI protocol is utilized in conjunction with read/write monitors,instead of explicitly providing a new cache coherency state in a cachestate array; this is potentially useful when monitors/attributes areincluded elsewhere (i.e. not implemented in cache 150's state array).But the actions of control logic in regards to local and globalobservability remain relatively the same.

Note that the terms internal and external are often relative to aperspective of a thread associated with execution of atransaction/critical section or processing elements that share a cache.For example, a first processing element for executing a software threadassociated with execution of a transaction or a critical section isreferred to a local thread. Therefore, in the discussion above, if astore to or load from an address previously written by the first thread,which results in a cache line for the address being held in a bufferedcoherency state (or a coherency state associated with a read or writemonitor state), is received; then the buffered version of the cache lineis provided to the first thread since it is the local thread. Incontrast, a second thread may be executing on another processing elementwithin the same processor, but is not associated with execution of thetransaction responsible for the cache line being held in the bufferedstate—an external thread; therefore, a load or store from the secondthread to the address misses the buffered version of the cache line andnormal cache replacement is utilized to retrieve the unbuffered versionof the cache line from higher level memory. In one scenario, thiseviction may result in an abort (or at least a conflict between threadsthat is to be resolved in some fashion). Note from this discussion thatreference below to a ‘processor’ in a transactional (or HLE) mode mayrefer to the entire processor or only a processing element thereof thatis to execute (or be associated with execution of) atransaction/critical section.

Although much of the discussion above has been focused on transactionalexecution, hardware or speculative lock elision (HLE or SLE) may besimilarly utilized. As mentioned above, critical sections are demarcatedor defined by a programmer's use of lock instructions and subsequentlock release instructions. Or in another scenario, a user is capable ofutilizing begin and end critical section instructions (e.g. lock andlock release instructions with associated begin and end hints todemarcate/define the critical sections). In one embodiment, explicitlock or lock release instructions are utilized. For example, in Intel®'scurrent IA-32 and Intel®® 64 instruction set an Assert Lock# SignalPrefix, which has opcode F0, may be pre-pended to some instructions toensure exclusive access of a processor to a shared memory. Here, aprogrammer, compiler, optimizer, translator, firmware, hardware, orcombination thereof utilizes one of the explicit lock instructions incombination with a predefined prefix hint to indicate the lockinstruction is hinting a beginning of a critical section.

However, programmers may also utilize address locations as metadata orlocks for locations as a construct of software. For example, aprogrammer using a first address location as a lock/meta-data for afirst hash table sets the value at the first address location to a firstlogical state, such as zero, to represent that the hash table may beaccessed, i.e. unlocked. Upon a thread of execution entering the hashtable, the value at the first address location will be set to a secondlogical value, such as a one, to represent that the first hash table islocked. Consequently, if another thread wishes to access the hash table,it previously would wait until the lock is reset by the first thread tozero. As a simplified illustrative example of an abstracted lock, aconditional statement is used to allow access by a thread to a sectionof code or locations in memory, such as if lock_variable is the same as0, then set the lock_variable to 1 and access locations within the hashtable associated with the lock_variable. Therefore, any instruction (orcombination of instructions) may be utilized in conjunction with aprefix or hint to start a critical section for HLE.

A few examples of instructions that are not typically considered“explicit” lock instructions (but may be used as instructions tomanipulate a software lock) include, a compare and exchange instruction,a bit test and set instruction, and an exchange and add instruction. InIntel®'s IA-32 and IA-64 instruction set, the aforementionedinstructions include CMPXCHG, BTS, and XADD, as described in Intel®® 64and IA-32 instruction set documents discussed above. Note thatpreviously decode logic 125 is configured to detect the instructionsutilizing an opcode field or other field of the instruction. As anexample, CMPXCHG is associated with the following opcodes: 0F B0/r,REX+0F B0/r, and REX·W+0F B1/r.

In another embodiment, operations associated with an instruction areutilized to detect a lock instruction. For example, in x86 the followingthree memory micro-operations are used to perform an atomic memoryupdate of a memory location indicating a potential lock instruction: (1)Load_Store_Intent (L_S_I) with opcode 0x63; (2) STA with opcode 0x76;and (3) STD with opcode 0x7F. Here, L_S_I obtains the memory location inexclusive ownership state and does a read of the memory location, whilethe STA and STD operations modify and write to the memory location. Inother words, the lock value at the memory location is read, modified,and then a new modified value is written back to the location. Note thatlock instructions may have any number of other non-memory, as well asother memory, operations associated with the read, write, modify memoryoperations. As can be seen from this discussion, use of the phrase“eliding a lock instruction”, “lock elision”, or other reference toelision regarding a lock instruction potentially refers to elision(omission) of a part of a lock instruction. In one illustrative example,eliding a lock instruction refers to eliding the external store portionof the lock instruction to update/modify the memory location utilized asa software lock.

In addition, in one embodiment, a lock release instruction is apredetermined instruction or group of instructions/operations. However,just as lock instructions may read and modify a memory location, a lockrelease instruction may only modify/write to a memory location. As aconsequence, in one embodiment, any store/write operation is potentiallya lock-release instruction. And similar to the begin critical sectioninstruction, a hint (e.g. prefix) may be added to a lock releaseinstruction to indicate an end of a critical section. As stated above,instructions and stores may be identified by opcode or any other knownmethod of detecting instructions/operations.

In some embodiments, detection of corresponding lock and lock releaseinstructions that define a critical section (CS) are performed inhardware. In combination with prediction, hardware may also includeprediction logic to predict critical sections based on empiricalexecution history. For example, predication logic stores a predictionentry to represent whether a lock instruction begins a critical sectionor not, i.e. is to be elided in the future, such as upon a subsequentdetection of the lock instruction. Such detection and prediction mayinclude complex logic to detect/predict instructions that manipulate alock for a critical section; especially those that are not explicit lockor lock release.

The techniques described above in reference to critical sectiondetection and prediction solely in hardware is often referred to asHardware Lock Elision (HLE). However, in another embodiment, suchdetection is performed in a software environment, such as with acompiler, translator, optimizer, kernel, or even application code; thismay be referred to herein as (Speculative Lock Elision or Software LockElision (SLE)). Although it's common to refer to SLE and HLEinterchangeably in some circumstances, as hardware performs the actuallock elision. Here, software determines critical sections (i.e.identifies lock and lock release pairs). And hardware is configured torecognize software's hints/identification, such that the complexity ofhardware is reduced, while maintaining the same functionality.

As a first example, a programmer utilizes (or a compiler inserts)xAcquire and xRelease instructions to define critical sections. Here,lock and lock release instructions are augmented/modified/transformed(i.e. a programmer chooses to utilize xAcquire and xRelease or a prefixto represent xAcquire and xRelease is added to bare lock and lockrelease instructions by a compiler or translator) to hint at a start andend of a critical section (i.e. a hint that the lock and lock releaseinstructions are to be elided). As a result, code utilizing xAcquire andxRelease, in one embodiment are legacy compliant. Here, on a legacyprocessor that doesn't support SLE, the prefix of xAcquire is simplyignored (i.e. there is no support to interpret the prefix because SLE isnot supported), so the normal lock, execute, and unlock executionprocess is performed. Yet, when the same code is encountered on a SLEsupported processor, then the prefix is interpreted correctly andelision is performed to execute the critical section speculatively.

And since memory accesses after eliding the lock instruction aretentative (i.e. they may be aborted and reset back to the saved registercheckpoint state), the accesses are tracked/monitored in a similarmanner to monitoring hardware transactions, as described above. Whentracking the tentative memory accesses, if a data conflict does occur,then the current execution is potentially aborted and rolled back to aregister checkpoint. For example, assume two threads are executing onprocessor 100. Thread 101A detects the lock instruction and is trackingaccesses in lower level data cache 110. A conflict, such as thread 102Awriting to a location loaded from by thread 101A, is detected. Here,either thread 101A or thread 102A is aborted, and the other ispotentially allowed to execute to completion. If thread 101A is aborted,then in one embodiment, the register state is returned to the registercheckpoint, the memory state is returned to a previous memory state(i.e. buffered coherency states are invalidated or selected for evictionupon new data requests) and the lock instruction, as well as thesubsequently aborted instructions, are re-executed without eliding thelock. Note that in other embodiments, thread 101 a may attempt toperform a late lock acquire (i.e. acquire the initial lock on-the-flywithin the critical section as long as the current read and write setare valid) and complete without aborting.

Yet, assume tracking the tentative accesses does not detect a dataconflict. When a corresponding lock release instruction is found (e.g. alock release instruction that was similarly transformed into a lockrelease instruction with an end critical section hint), the tentativememory accesses are atomically committed, i.e. made globally visible. Inthe above example, the monitors/tracking bits are cleared back to theirdefault state. Moreover, the store from the lock release instruction tochange the lock value back to an unlock value is elided, since the lockwas not acquired in the first place. Above, a store associated with thelock instruction to set the lock was elided; therefore, the addresslocation of the lock still represents an unlocked state. Consequently,the store associated with the lock release instruction is also elided,since there is potentially no need to re-write an unlock value to alocation already storing an unlocked value.

In one embodiment, processor 100 is capable of executing a compiler,optimization, and/or translator code 177 to compile application code 176to support transactional execution, as well as to potentially optimizeapplication code 176, such as perform re-ordering. Here, the compilermay insert operations, calls, functions, and other code to enableexecution of transactions, as well as detect and demarcate criticalsections for HLE or transactional regions for RTM.

Compiler 177 often includes a program or set of programs to translatesource text/code into target text/code. Usually, compilation ofprogram/application code 176 with compiler 177 is done in multiplephases and passes to transform hi-level programming language code intolow-level machine or assembly language code. Yet, single pass compilersmay still be utilized for simple compilation. Compiler 177 may utilizeany known compilation techniques and perform any known compileroperations, such as lexical analysis, preprocessing, parsing, semanticanalysis, code generation, code transformation, and code optimization.The intersection of transactional execution and dynamic code compilationpotentially results in enabling more aggressive optimization, whileretaining necessary memory ordering safeguards.

Larger compilers often include multiple phases, but most often thesephases are included within two general phases: (1) a front-end, i.e.generally where syntactic processing, semantic processing, and sometransformation/optimization may take place, and (2) a back-end, i.e.generally where analysis, transformations, optimizations, and codegeneration takes place. Some compilers refer to a middle, whichillustrates the blurring of delineation between a front-end and back endof a compiler. As a result, reference to insertion, association,generation, or other operation of a compiler may take place in any ofthe aforementioned phases or passes, as well as any other known phasesor passes of a compiler. As an illustrative example, a compiler 177potentially inserts transactional operations, calls, functions, etc. inone or more phases of compilation, such as insertion of calls/operationsin a front-end phase of compilation and then transformation of thecalls/operations into lower-level code during a transactional memorytransformation phase. Note that during dynamic compilation, compilercode or dynamic optimization code 177 may insert such operations/calls,as well as optimize the code 176 for execution during runtime. As aspecific illustrative example, binary code 176 (already compiled code)may be dynamically optimized during runtime. Here, the program code 176may include the dynamic optimization code, the binary code, or acombination thereof.

Nevertheless, despite the execution environment and dynamic or staticnature of a compiler 177; the compiler 177, in one embodiment, compilesprogram code to enable transactional execution, HLE and/or optimizesections of program code. Similar to a compiler, a translator, such as abinary translator, translates code either statically or dynamically tooptimize and/or translate code. Therefore, reference to execution ofcode, application code, program code, a STM environment, or othersoftware environment may refer to: (1) execution of a compilerprogram(s), optimization code optimizer, or translator eitherdynamically or statically, to compile program code, to maintaintransactional structures, to perform other transaction relatedoperations, to optimize code, or to translate code; (2) execution ofmain program code including transactional operations/calls, such asapplication code that has been optimized/compiled; (3) execution ofother program code, such as libraries, associated with the main programcode to maintain transactional structures, to perform other transactionrelated operations, or to optimize code; or (4) a combination thereof.

Often within transactional memory environment, a compiler will beutilized to insert some operations, calls, and other code in-line withapplication code to be compiled, while other operations, calls,functions, and code are provided separately within libraries. Thispotentially provides the ability of the software distributors tooptimize and update the libraries without having to recompile theapplication code. As a specific example, a call to a commit function maybe inserted inline within application code at a commit point of atransaction, while the commit function is separately provided in anupdateable STM library. And the commit function includes an instructionor operation, when executed, to reset monitor/attribute bits, asdescribed herein. Additionally, the choice of where to place specificoperations and calls potentially affects the efficiency of applicationcode. As another example, binary translation code is provided in afirmware or microcode layer of a processing device. So, when binary codeis encountered, the binary translation code is executed to translate andpotentially optimize the code for execution on the processing device,such as replacing lock instruction and lock release instruction pairswith xAcquire and xEnd instructions (discussed in more detail below).

In one embodiment any number of instructions (or different version ofcurrent instructions) are provided to aid thread level speculation (i.e.transactional memory and/or speculative lock elision). Here, decoders125 are configured (i.e. hardware logic is coupled together in aspecific configuration) to recognize the defined instructions (andversions thereof) to cause other stages of a processing element toperform specific operations based on the recognition by decoders 125. Anillustrative list of such instructions include: xAcquire (e.g. a lockinstruction with a hint to start lock elision on a specified memoryaddress); xRelease (e.g. a lock release instruction to indicate arelease of a lock, which may be elided); SLE Abort (e.g. abortprocessing for an abort condition encountered during SLE/HLE execution)xBegin (e.g. a start of a transaction); xEnd (e.g. an end of atransaction); xAbort (e.g. abort processing for an abort conditionduring execution of a transaction); test speculation status (e.g.testing status of HLE or TM execution); and enable speculation (e.g.enable/disable HLE or TM execution).

Referring to FIGS. 2-4, embodiments of a computer system configurationsadapted to include processors that are to provide abort controlmechanisms are illustrated. In reference to FIG. 2, an illustrativeexample of a two processor system 200 with an integrated memorycontroller and Input/Output (I/O) controller in each processor 205, 210is depicted. Although not discussed in detail to avoid obscuring thediscussion, platform 200 illustrates multiple interconnects to transferinformation between components. For example, point-to-point (P2P)interconnect 215, in one embodiment, includes a serial P2P,bi-directional, cache-coherent bus with a layered protocol architecturethat enables high-speed data transfer. Moreover, a commonly knowninterface (Peripheral Component Interconnect Express, PCIE) or variantthereof is utilized for interface 240 between I/O devices 245, 250.However, any known interconnect or interface may be utilized tocommunicate to or within domains of a computing system.

Turning to FIG. 3 a quad processor platform 300 is illustrated. As inFIG. 2, processors 301-304 are coupled to each other through ahigh-speed P2P interconnect 305. And processors 301-304 includeintegrated controllers 301 c-304 c. FIG. 4 depicts another quad coreprocessor platform 400 with a different configuration. Here, instead ofutilizing an on-processor I/O controller to communicate with I/O devicesover an I/O interface, such as a PCI-E interface, the P2P interconnectis utilized to couple the processors and I/O controller hubs 420. Hubs420 then in turn communicate with I/O devices over a PCIE-likeinterface.

Referring next to FIG. 5, an embodiment of modules/logic to provideabort control mechanisms is illustrated. As an example, singleinstruction 501 is illustrated; however, numeral 501 will be discussedin reference to a number of instructions that may be supported byprocessor 500 for thread level speculation (e.g. exemplary instructionimplementations are demonstrated through pseudo code in FIGS. 6-7).Specifically, a single instruction (instruction 501) is shown forsimplicity. However, as each example and figure is discussed, differentinstructions are presented in reference to instruction 501. In onescenario, instruction 501 is an instruction that is part of code, suchas application code, user-code, a runtime library, a softwareenvironment, etc. And instruction 501 is recognizable by decode logic515. In other words, an Instruction Set Architecture (ISA) is definedfor processor 500 including instruction 501, which is recognizable byoperation code (op code) 501 o. So, when decode logic 515 receives aninstruction and detects op code 501 o, it causes other pipeline stages520 and execution logic 530 to perform predefined operations toaccomplish an implementation or function that is defined in the ISA forspecific instruction 501.

As discussed above, two types of thread level speculation techniques areprimarily discussed herein—transactional memory (TM) and speculativelock elision (SLE). Transactional memory, as described herein, includesthe demarcation of a transaction (e.g. with new begin and endtransactional instructions) utilizing some form of code or firmware,such that a processor that supports transactional execution (e.g.processor 500) executes the transaction tentatively in response todetecting the demarcated transaction, as described above. Note that aprocessor, which is not transactional memory compliant (i.e. doesn'trecognize transactional instructions, which are also viewed as legacyprocessors from the perspective of new transactional code), are not ableto execute the transaction, since it doesn't recognize a new opcode 5010for transactional instructions.

In contrast, SLE (in some embodiments) is made legacy compliant. Here, acritical section is defined by a lock and lock release instruction. Andeither originally (by the programmer) or subsequently (by a compiler ortranslator) the lock instruction is augmented with a hint to indicatelocks for the critical section may be elided. Then, the critical sectionis executed tentatively like a transaction. As a result, on an SLEcompliant processor, such as processor 500, when the augmented lockinstructions (e.g. lock instructions with associated elision hints) aredetected, hardware is able to optionally elide locks based on the hint.And on a legacy processor, the augmented portions of the lockinstructions are ignored, since the legacy decoders aren't designed orconfigured to recognize the augmented portions of the instruction. Notethat in one scenario, then augmented portion is an intelligentlyselected prefix that legacy processors were already designed to ignore,but newly designed processors will recognize. Consequently, on legacyprocessors, the critical section is executed in a tradition manner withlocks. Here, the lock may serialize threaded access to shared data (andtherefore execution), but the same code is executable on both legacy andnewly designed processors. So, processor designers don't have toalienate an entire market segment of users that want to be able to uselegacy software on newly designed computer systems.

To provide an illustrative operating environment for a betterunderstanding, two oversimplified execution examples—execution of acritical section utilizing SLE and execution of a transaction utilizingTM—are discussed in reference to processor 500 of FIG. 5.

Starting with the first example, assume program code includes a criticalsection. The start of the critical section, in this example, is definedby a lock acquire instruction 501; whether utilized by the programmer orinserted by compiler/translator/optimizer code. As discussed above, alock acquire instruction includes a previous lock instruction (e.g.identified by opcode 501 o) augmented with a hint (e.g. prefix 501 p).In one embodiment, a lock acquire instruction 501 includes an xAcquireinstruction with a SLE hint prefix 501 p added to a previous lockinstruction. Here, the SLE hint prefix 501 p includes a specific prefixvalue that indicates to decode logic 515 that the lock instructionreferenced by opcode 5010 is to start a critical section.

As stated above, a previous lock instruction may include an explicitlock instruction. For example, in Intel®'s current IA-32 and Intel®® 64instruction set an Assert Lock# Signal Prefix, which has opcode F0, maybe pre-pended to some instructions to ensure exclusive access of aprocessor to a shared memory. Or the previous lock acquire instructionincludes instructions that are not “explicit,” such as a compare andexchange instruction, a bit test and set instruction, and an exchangeand add instruction. In Intel®'s IA-32 and IA-64 instruction set, theaforementioned instructions include CMPXCHG, BTS, and XADD, as describedin Intel®® 64 and IA-32 instruction set documents. In these documentsCMPXCHG is associated with the following opcodes: 0F B0/r, REX+0F B0/r,and REX·W+0F B1/r. Yet, a lock acquire instruction (in some embodiments)is not limited to a specific instruction, but rather the operationsthereof. For example, in x86 the following three memory micro-operationsare used to perform an atomic memory update of a memory locationindicating a potential lock instruction: (1) Load_Store_Intent (L_S_I)with opcode 0x63; (2) STA with opcode 0x76; and (3) STD with opcode0x7F. Here, L_S_I obtains the memory location in exclusive ownershipstate and does a read of the memory location, while the STA and STDoperations modify and write to the memory location. In other words, thelock value at the memory location is read, modified, and then a newmodified (locked) value is written back to the location. Note that lockinstructions may have any number of other non-memory, as well as othermemory, operations associated with the read, write, modify memoryoperations.

In a first usage of xAcquire 501, a programmer creating application orprogram code utilizes xAcquire to demarcate a beginning of a criticalsection that may be executed using SLE (i.e. either through ahigher-level language or other identification of a lock instruction thatis translated into SLE hint prefix 501 p associated with opcode).Essentially, a programmer is able to create a versatile program that isable to run on legacy processors with traditional locks or on newprocessors utilizing HLE. In another usage, either as part of legacycode or by the choice (or lack of knowledge of newer programmingtechniques) of the programmer, a traditional lock instruction (examplesof which are discussed immediately above) is utilized. And code (e.g. astatic compiler, a dynamic compiler, a translator, an optimizer, orother code) detects critical sections within the program code. Thedetection is not discussed in detail; however, a few examples are given.First, any of the instructions or operations above are identified by thecode and replaced or modified with xAcquire instruction 501. Here,prefix 501 p is appended to previous instruction 501 (i.e. opcode 5010with any other instruction and addressing information, such as memoryaddress 501 ma). As another example, the code tracks stores/loads ofapplication code and determines lock and lock release pairs that definea potential critical section. And as above, the code inserts xAcquireinstruction 501 at the beginning of the critical section.

In a very similar manner, xRelease is utilized at the end of a criticalsection. Therefore, whether the end of a critical section (e.g. a lockrelease) is identified by the programmer or by subsequent code, xReleaseis inserted at the end of the critical section. Here, xReleaseinstruction 501 has an opcode that identifies an operation, such as astore operation to release a lock (or a no-operation in an alternativeembodiment), and a xRelease prefix 501 p to be recognized by SLEconfigured decoders.

In response to decoding xAcquire 501, processor 500 enters HLE mode. HLEexecution is then started i. In one embodiment, the current registerstate is checkpointed (stored) in checkpoint logic 545 in case of anabort. And memory state tracking is started (i.e. the hardware monitorsdescribed above begin to track memory accesses from the criticalsection). For example, accesses to a cache are monitored to ensure theability to roll-back (or discard updates to) the memory state in case ofan abort. If the lock elision buffer 535 is available, then it'sallocated, address and data information is recorded for forwarding andcommit checking, and elision is performed (i.e. the store to update alock at the memory address 501 ma is not performed). In other words,processor 500 does not add the address of the lock to the transactionalregion's write-set nor does it issue any write requests to the lock.Instead, the address of the lock is added to the read set, in oneexample. And the lock elision buffer 535, in one scenario, includes thememory address 501 ma and the lock value to be stored thereto. As aresult, a late lock acquire or subsequent execution may be performedutilizing that information. However, since the store to the lock is notperformed, then the lock globally appears to be free, which allows otherthreads to execute concurrently with the tracking mechanisms acting assafeguards to data contention. Yet, from a local perspective, the lockappears to be obtained, such that the critical section is able toexecute freely. Note that if lock elision buffer 535 is not available,then in response the lock operation is executed atomically withoutelision.

As can be seen, within the critical section, execution behaves like atransaction (free, concurrent execution with monitors and contentionprotocols to detect conflicts, such that multiple threads are notserialized unless an actual conflict is detected). Note that SLE/HLEenabled software is provided the same forward progress guarantees byprocessor 500 as the underlying non-HLE lock-based execution. In otherwords, if tentative or speculative execution of a critical section withHLE fails, then the critical section may be re-executed with a legacylocking system. Also, in some embodiment, processor 500 is abletransition to non-transactional execution without performing atransactional abort.

Once the end of the critical section is reached, then the xReleaseinstruction 501 is fetched by the front-end logic 510 and decoded bydecode logic 515. As stated above, xRelease instruction 501, in oneembodiment, includes a store to return the lock at memory address 501 maback to an unlocked value. However, if the original store from thexAcquire instruction was elided, then the lock at memory address 501 mais still unlocked (as long as not other thread has obtained the lock).Therefore, the store to return the lock in xRelease is unnecessary.

Consequently, decoders 515 are configured to recognize the storeinstruction from opcode 5010 and the prefix 501 p to hint that lockelision on the memory address 501 ma specified by xAcquire and/orxRelease is to be ended. Note that the store or write to lock 501 ma iselided when xRelease is to restore the value of the lock to the value ithad prior to the XACQUIRE prefixed lock acquire operation on the samelock. However, in a versioning system (i.e. incrementing metadata valuesin locks to determine a most recent transaction/critical section tocommit) the lock value may be incremented. Here, xRelease is to hint atan end to elision, but the store to memory address 501 ma is performed.A commit of the critical section is completed, elision buffer 535 isdeallocated, and HLE mode is exited.

As mentioned above, in some legacy hardware implementations that do notinclude HLE support, the XACQUIRE and XRELEASE prefix hints are ignored.And as a result, elision will not be performed, since these prefixes, inone embodiment, correspond to the REPNE/REPE IA-32 prefixes that areignored on the instructions where XACQUIRE and XRELEASE are valid.Moreover, improper use of hints by a programmer will not causefunctional bugs, as elision execution will continue correct, forwardprogress.

As aforementioned, if an abort condition (data contention, lockcontention, mismatching lock address/values, etc.) is encountered, thensome form of abort processing may be performed. Just as transactionalmemory and HLE are similar in execution, they may also be similar inportions of abort processing. For example, checkpointing logic 545 isutilized to restore a register state for processor 500. And the memorystate is restored to the previous critical section state in data cache540 (e.g. monitored cache locations are invalidated and the monitors arereset). Therefore, in one embodiment, the same or a similar version ofthe same abort instruction (xAbort 501) is utilized for both SLE and TM.Yet in another embodiment, separate xAbort instructions (with differentopcodes and/or prefixes) are utilized for HLE and TM. Moreover, abortprocessing for HLE may be implicit in hardware (i.e. performed as partof hardware in response to an abort condition without an explicit abortinstruction). In some implementations, the abort operation may cause theimplementation to report numerous causes of abort and other informationin either a special register or in an existing set of one or moregeneral purpose registers. The control mechanisms for aborting aspeculative code region are discussed in more detail below.

As a reminder, two oversimplified execution examples—execution of acritical section utilizing SLE and execution of a transaction utilizingTM—are currently being discussed. The exemplary execution of a criticalsection utilizing xAcquire and xRelease has been covered. Therefore, thedescription now moves to discussion of exemplary execution of atransaction using transactional memory—also referred to as RestrictedTransactional Memory (RTM) or Hardware transactional Memory(HTM)—techniques.

Much like a critical section, a transaction is demarcated by specificinstructions. However, in one embodiment, instead of a lock and lockrelease pair with prefixes, the transaction is defined by a begin(xBegin) transaction instruction and end (xEnd) transaction instruction(e.g. new instructions instead of augmented previous instructions). Andsimilar to SLE, a programmer may choose to use xBegin and xEnd to mark atransaction. Or software (e.g. a compiler, translator, optimizer, etc.)detects a section of code that could benefit from atomic ortransactional execution and inserts the xBegin, xEnd instructions.

As an example, a programmer uses the XBEGIN instruction to specify astart of the transactional code region and the XEND instruction tospecify the end of the transactional code region. Therefore, when axBegin instruction 501 is fetched by fetch logic 510 and decoded bydecode logic 515, processor 500 executes the transactional region like acritical section (i.e. tentatively while tracking memory accesses andpotential conflicts thereto). And if a conflict (or other abortcondition) is detected, then the architecture state is rolled back tothe state stored in checkpoint logic 545, the memory updates performedduring RTM execution are discarded, execution is vectored to thefallback address provided by the xBegin instruction 501, and any abortinformation is reported accordingly. Here, an XEND instruction is todefine an end of a transaction region. Often the region execution isvalidated (ensure that no actual data conflicts have occurred) and thetransaction is committed or aborted based on the validation in responseto an XEND instruction. In some implementations, XEND is to be globallyordered and atomic. Other implementations may perform XEND withoutglobal ordering and require programmers to use a fencing operation. TheXEND instruction, in one embodiment, may signal a general purposeexception (#GP) when used outside a transactional region.

The two examples of speculative code region execution—HLE and RTM—havebeen discussed above. And in reference to both of these examples, thefocus on instructions and the format thereof has been on the boundaryinstructions (e.g. acquire, release, begin, and end). However,discussion of the instructions available within a speculative coderegion is also worthwhile.

In one embodiment, once a speculative code region is started by anXAQURIE OR XBEGIN, then the subsequent instruction are, by default,assumed to be speculative (i.e. transactional). Here, a programmerincludes a new XBEGIN instruction for a transaction. But the memoryaccess operations are typical, previous memory instructions, such as MOVrxx, mxx. And since they are included within a defined transaction, theyinstructions are treated as transactional memory access operations.

In an alternative embodiment, instructions/operations within a coderegion are, by default, non-transactional. Here, new transactionalmemory access operations (either identified by new opcodes or newprefixes added to old instructions) are utilized. As an example, if aprevious MOV r32, m32 instruction is utilized within a transaction, thenit's treated non-transactionally by default; which in some cases maycause an abort. However, if the MOV r32, m32 is associated with atransactional prefix or an XNMOV r32, m32 with a new transactionalopcode is utilized then the instruction is treated transactionally.

Although alternative embodiments for how operations within a speculativecode region are discussed above, in another embodiment, transactionaland non-transactional operations, may be mixed within a speculative coderegion. Here, assume operations within a speculative code region aretreated trasnsactionally (or tentatively) by default. In this scenario,the ISA may define explicit non-transactional instructions, such asXNMOV r32, m32 and XNMOV m32,r32, that allow a programmer to ‘escape’the speculative nature of a code region and perform a non-transactionalmemory operation. Also note that, in one embodiment, different defaultsmay be utilized for HLE versus TM. For example, within HLE sectionsoperations may be interpreted as non-transactional in nature, since theoriginal programmer may have initially contemplated non-transactionaloperations protected by locks, while a compiler or other softwaretransformed this code region into a critical section to be executed bylock elision. And in this example, TM sections may by interpreted bydefault as transactional.

In both instances of the example speculative code region execution (e.g.HLE and TM) there was mention of aborting the speculative code regions.And furthermore, there was some discussion of how the end result abortprocessing may be performed (i.e. checkpoint logic 545 rolls-back anarchitectural state of processor 500—or the processing element ofprocessor 500—to a checkpoint at the start of the speculative coderegion and the tentative updates to memory (memory state) are discardedin cache 540. Yet, to this point there has been no specific discussionof how the abort decision is made or the control mechanisms thereof.

In one embodiment, processor 500 includes abort event logic 565configured to track potential speculative code region abort events. Anda decision is made whether a speculative code region is to abort basedon policies defined in hardware, firmware (e.g. microcode), code (e.g.privileged hypervisor or application code), or a combination thereof. Asillustrated, abort event logic 565 is illustrated as separate from otherlogic/modules of processor 500. However, just as the other depictedrepresentations of logical modules may cross/overlap other boundaries,so may abort event logic 565.

For example, a common speculative code region abort event includesdetection of a conflict regarding a memory address within the coderegion's read or write set. Here, assume cache 540 includes a cache linewith a read monitor set for a current speculative code region. And asnoop to write from another processing element on processor 500 is madeto the cache line, so the other processing element can obtain the linein an exclusive state and modify it. In this scenario, cache controllogic indicates a conflict (i.e. the cache line is marked astransactionally read as part of the read set and an external processingelement wants to write to the line). Therefore, in one embodiment (asdiscussed in more detail below) this conflict is recorded in abortstatus register 536. As can be seen from this example, detection of thepotential abort event was purely made within cache 540. But in oneembodiment, reference to abort event logic 565 includes cache 540'slogic to perform the conflict detection. As can be seen, any definedabort event may have distributed logic to detect the abort event. Asanother example, timer(s) 560 may be utilized to timeout a speculativecode region to ensure forward progress. So the timer and expirationthereof, in one embodiment, is considered within or part of abort eventlogic 565.

Once one or more aborts are defined (i.e. tracked in register 536), thenthe interpretation of the potential abort event becomes the topic ofconversation. In one embodiment, hardware defines the abort policy. Asan example, abort storage element 536 holds a representation of detectedabort events. And logic combinations are configured in a specific mannerto define what abort events are ignored or cause an abort of the codespeculative region. As a purely oversampled and illustrative example,assume a hardware designer always wants to abort when an explicit abortinstruction is detected or when a data conflict is detected. Here,assuming a logical high represents an abort occurring and a logical highoutput initiates and actual abort, then an OR logical gate (or invertedNOR gate) is coupled to the bit positions of abort status register 536corresponding to the data conflict and explicit abort events. Therefore,if either bit position is set high upon an occurrence of the event, thenthe resulting logical high from the OR logical gate for an abort controlsignal initiates an abort of the speculative code region. Extrapolatingfrom this simple example, hardware may predefine abort events that arehandled normally, ignored, or sent to firmware or software forinterpretation. And in one implementation, hardware may allow firmwareor software to dynamically update its default abort policies (i.e.control mechanisms). Moreover, in some implementations, it may beadvantageous to enable an ‘always abort’ speculative code region, sodesigners/programmers are able to test/debug abort fall back paths (e.g.a fall back defined in hardware, a fall back defined by an XBEGINinstruction, and/or a fall back defined by an XBORT argument). Here, oneor more bits in a register, such as abort register 536 is set (byhardware, firmware, and/or software) to an abort value to indicate tohardware that all speculative code regions are to be aborted. In thisscenario, hardware automatically interprets the always abort indicationas an abort.

In the previous example, hardware defined the potential abort events fordetection and defined what scenario (single or combination of thoseevents) would cause an abort of a speculative code region. However, inother embodiments, both the definition of abort events to track and thescenarios for causing an abort may be defined by hardware, firmware,software, or a combination thereof. As an example, a mask may provideaccess to different privilege levels of software to abort register 536to define what abort events to track. Note the mask may allow hardwareto predefine a few abort events that are always tracked (and/or alwayscause an abort) to guarantee forward progress, while enabling softwareto turn on/off tracking of other abort events/conditions. Furthermore,different levels of decisions may be made (e.g. hardware makes aninitial determination of whether or not to even inform code of the abortconditions tracked; and if software is informed, then it makes adecision whether to abort based on the informed abort events). Or inanother embodiment, hardware automatically initiates an abort of aspeculative code region when specific abort conditions (e.g. an explicitabort instruction, data conflict, memory operation type, timerexpiration etc.) are detected. But hardware leaves the decision forother abort conditions (e.g. memory ordering, internal buffer overflow,or an I/O access) to software.

Turning to FIG. 6, an embodiment of a layered approach for speculativeabort control mechanisms is illustrated. Here, abort events register 605defines a plurality of abort events that may be tracked. In oneembodiment, hardware, firmware, software, or a combination thereof mayenable or disable tracking of one or more of the abort events. Andsimilarly, in one implementation, hardware, firmware, software, or acombination thereof is able to specify what abort events (or scenario ofabort events) is to be ignored, treated normally, sent to firmware 610,sent to software 615, or cause an abort.

As depicted, register 605 includes a bit map of bit positions that eachrepresents an abort condition/event. However, it's important to notethat this is purely illustrative. More than one bit position may beutilized to define an abort condition. And different abort events may berepresented in more than one storage element, instead of in a singleregister (as depicted). As an illustrative list of potential abortevents includes: an explicit abort instruction (e.g. XABORT recognizedas part of an ISA for a processor including register 605); a memoryaddress conflict (e.g. an external logical processor writes to aspeculatively read location, read from a location speculatively written,and/or acquire a lock for a speculative code region); a buffer overflow(e.g. a line from cache that is marked as speculatively accessed isevicted indicating the cache is not able to hold all of the speculativeinformation); a debug breakpoint hit (e.g. a point in the speculativecode region is hit to break execution for debug); a nested transactionevent (e.g. an abort during a nested transaction or exceeding a maximumnested transaction depth); an abort timer expiration (e.g. a timerexpires indicating a speculative code region is to abort); a persistentmemory access (e.g an I/O write when it's not allowed); a memoryordering violation; an operation attribute abort (e.g. an disallowedmemory type, disallowed attribute information—i.e. general, system, x87,Multi-Media eXtensions (MMX), Single Instruction Multiple Data (SIMD),SIMD Extensions (SSE), Virtual Machine eXtensions (VMX), Safer ModeeXtensions (SMX), or other known attributes that may be not allowedbased on designer selection, disallowed prefix, or other disallowedoperation related information); a parity error; an ECC error, an assist,a fault, an asynchronous event (e.g. an interrupt); an expiration ofother timers (e.g. VMXTIMER), etc. Note from the discussion above thatregister 605 may also have an ‘always abort’ bit that will cause allspeculative code regions to abort when set. In differentimplementations, a designer allows hardware, firmware, privilegedsoftware, user-level software or a combination thereof to access the‘always abort’ bit.

As stated above, tracking of one or more abort events, in oneembodiment, are capable of being enabled/disabled. As an example,microcode, privileged level code (e.g OS or virtual machine monitor),and/or user-level software (e.g. application/program code) is able toaccess an enable/disable register, such as a mask, to enable/disabletracking (or recording) of abort events. As an example, different levelsof access to register 605 may be provided based on privilege level (e.g.hardware reserves abort conditions, such as entry 0 and 2; a hypervisoror privileged level software may enable/disable 3-9, and user-levelsoftware may enable/disable 6-9). Note that ‘scenarios’ (e.g. acombination of abort events) may similarly be defined.

When an abort condition is detected (i.e. the corresponding bit inregister 605 is set based on the detecting the event), then it'sdetermined if an abort of a current speculative code region is to beperformed. Just as above with tracking, hardware, firmware layer 610,software layer 615, or a combination thereof makes the abort decisionbased on the information residing in abort register 605. In oneembodiment, hardware defines specific events that trigger an abort. Andthe abort itself may also be handled solely in hardware (e.g. rollbackof architecture state with checkpoint logic and discarding speculativememory state from memory). Or hardware determines an abort is to occurand passes the abort control over to firmware layer 610 (e.g. microcode)and/or software layer 615 (e.g. hypervisor or user-level code) to managethe abort processing. In another embodiment, firmware layer 610 and/orsoftware layer 615 defines conditions that cause an abort. Here, settinga corresponding bit may cause an asynchronous transfer to firmware layer610 or software layer 615 to perform an abort decision based on thedefined conditions. Or register 605 is synchronously polled. Either way,based on a detected abort event, firmware 610/software 615 makes anabort determination in this embodiment.

Yet, in another embodiment, a combination of hardware, firmware 610, andsoftware 615 is utilized to make abort determinations. Here, hardwaretracks abort events in register 605. And hardware is able to determineif a detected abort even is to be handled normally (i.e. immediatelycause an abort and rollback), ignored (i.e. doesn't cause an abort), orsent/transferred to a microcode handler in firmware layer 610 to make adecisions. In other words, hardware operates as a first pass, whereobvious (non-complex) abort events/scenarios may be handled. And otherabort events are passed up (either to firmware layer 610 or softwarelayer 615 depending on the implementation) for further decision making.Once firmware layer 610 receives the information from hardware, it maymake an abort determination (e.g. a second pass or level ofdetermination) or percolate the information up to software layer 615 forthe abort determination. In an alternate implementation, hardware tracksabort events in register 605. And firmware 610 and/or software 615 aredirectly informed of the abort events and make the abort determination(i.e. hardware is only tasked with tracking not abort determination,while the complex nature of abort decision making is left to handlers inmicrocode, privileged code, or user-level code).

Embodiments of flow diagrams for abort control mechanisms are discussedbelow in reference to FIGS. 7-8. To provide an illustrative operatingenvironment, these exemplary implementations may be discussed inreference to processor 500 and execution of a ‘speculative code region.’Note that a speculative code region (in different embodiments) refers toa transactional code region, critical section, and/or both. As isreadily apparent from this note, the discussion below in reference totransactional abort operations may be similarly applied to use in atransactional code region or a critical section.

Before discussion of embodiments for implementations of some abortcontrol mechanisms, it's also important to note that suchimplementations are depicted in the format of flow diagrams. These flowsmay be performed by hardware, firmware, microcode, privileged code,hypervisor code, program code, user-level code, or other code associatedwith a processor. For example, in one embodiment, hardware isspecifically configured or adapted to perform the flows. Note thathaving hardware or logic configured and/or specifically designed toperform one or more flows is different from general logic that is justoperable to perform such a flow by execution of code. Therefore, logicconfigured to perform a flow includes hardware logic designed to performthe flow. Additionally, the actual performance of the flows may beviewed as a method of performing, executing, enabling or otherwisecarrying out such abort control mechanisms. Here, code may bespecifically designed, written, and/or compiled to perform one or moreof the flows when executed by a processing element. However, each of theillustrated flows are not required to be performed during execution.Furthermore, other flows that are not depicted may also be performed.Moreover, the order of operations in each implementation is purelyillustrative and may be altered.

Referring next to FIG. 7, an embodiment of a flow diagram for a methodof providing an abort control mechanism is illustrated. Typically,during execution of a speculative code region, once a start instruction(e.g. xACQUIRE or xBEGIN) is encountered, processor 500 (or processingelement thereof) enters the corresponding speculation mode (e.g. HLE orRTM) in flow 705. And each of the memory access operations (i.e. loadsand stores), in one embodiment, are consideredspeculative/transactional. Therefore, if a load from memory isencountered, then the processing element in the speculation mode treatsit tentatively (i.e. adds the read to the transactional read set, suchas marks the memory address loaded from with a cache line monitor asspeculatively read).

In flow 710, an abort event is detected. As described above, any knownevent for aborting a speculative code region may be detected here. Inone embodiment, the abort event is recorded/identified in register 536,such as setting a bit in register 536 corresponding to the abort event.However, any known method of tracking an abort event andrecording/indicating the event occurred may be utilized.

In flow 715, it's determined if the detected abort event should cause anabort. In one implementation, when one or more specific abort events(e.g. an explicit abort instruction) are tracked in register 536,hardware automatically initiates an abort according to a predefinedpolicy. In other words, hardware includes a predefined policy foraborting based on specific events. In one scenario, this predefinedpolicy may be updated dynamically by firmware or software duringruntime. As a result, hardware still makes the determination upondetection of an event. But code is able to setup that predefined policyahead of time to define which events cause an abort.

In another embodiment, software makes the determination if an abortevent should cause an abort. Here, the abort event information is passedup to firmware, a microcode handler, a privileged level handler, auser-level handler, or other code to make the determination. In thisscenario, hardware either asynchronously (i.e. in an interrupt-likefashion) informs software of an abort event when a corresponding bit isupdated in register 536. Or software synchronously polls, such as a at acommit point to ensure no abort conditions have occurred, register 536(e.g. a specific abort event information to load from register 536 ortest one or more locations of register 536). Either way, once the abortevent information from register 536 is received by the code, then itmakes the determination in decision flow 715 based on its policy incomparison to the detected abort events.

In yet another embodiment, the determination in flow 715 is not solelyreserved by hardware or code, but rather made through cooperationthereof. For example, hardware is set (either by hardware design orsoftware programming) to abort upon specific abort events (i.e. whenspecific bits in register 536 are set to indicate specific abort eventshave occurred, then hardware initiates abort processing, which may becarried out in hardware, software, firmware, or a combination thereof).Yet, when other abort events are detected, they are simply ignored,which also may be set by hardware or code. And furthermore, when otherabort events are detected, that information is passed up tofirmware/software to determine whether they should be treated normally,ignored, or passed up to a higher layer.

Note the discussion above has primarily been in reference to detecting asingle abort condition (e.g. an explicit abort instruction) anddetermining in hardware, firmware, software, or a combination thereof ifan abort should be performed in flow 725 or processing continued (i.e.the event ignored) in flow 720. However, such abort conditions anddeterminations (in some embodiments) are not limited to a single abortevent. Instead, hardware, software, firmware, or a combination thereofmay define an abort scenario (i.e. a defined combination of more thanone abort event) that is to cause an abort. For example, a combinationof a nesting depth level (bit 5 from FIG. 6) and a buffer overflow (bit3 from FIG. 6) is utilized in a scenario. Here, an indication that amaximum nesting depth has been reached is provided (e.g. a nesting depthcounter incremented on each XBEGIN instruction reaches a maximumthreshold causing bit 5 of register 605 to be set). However, accordingto the policy in this implementation, an abort is not performed unlessbit 3 is set indicating resources have run out. In other words, amaximum nesting depth is provided and tracked, but an abort is notperformed unless the internal resources are also overflowed. As can beseen from this example, a scenario may be defined by any combination ofabort events being tracked or not tracked, as well as when to abort ornot abort based on those scenarios.

Turning to FIG. 8, an embodiment of flow diagram for a method of anabort control mechanism relating to timers for speculative code regionsis illustrated. As above, a speculative code region (e.g. criticalsection or transaction) is started (e.g. by an XACQUIRE or XBEGINinstruction). One or more timeout values are set for one or more timeoutcounters (timers) in flow 810. In one embodiment, timers have a defaultperiod. Here, a hardware designer may set a typical time for executionof a speculative code region that is proportionate to the availableresources for speculative code region execution. In another embodiment,a timer may or may not have a default timeout value, but code (e.g.privileged level code or user-level code) is able to set the timeoutvalue. In this scenario, an XBEGIN instruction or other operation maywrite a timeout value to a register upon starting the speculative coderegion in flow 805. And the timer is loaded with the timeout value tobegin counting upon starting the speculative code region. Executioncontinues normally in through flow 820. If an end to the speculativecode region is detected before the timer expiration, the timer is merelyreset and execution still continues normally in flow 820.

However, if the timer expires in flow 815 before an end to thespeculative code region (e.g. XRELEASE or XEND), then the timerexpiration is reported, such as in an abort register like register 605.And hardware, firmware, software, or a combination thereof determineswhether to actually abort the speculative code region as discussedabove. Above it was stated that there may be one or more timers. Forexample in one scenario, a timer is provided for each level of allowednesting, such that each nested critical section is associated with atimer and timeout value. As a result, setting timeout values in flow 810may be done at the start of each nested critical section. Here, thetimeout value is not required to be constant for each speculative coderegion, but rather outer code regions may have longer timeouts.

As a result, timer expiration aborts for speculative code regionspotentially guarantee forward progress in situations that otherwise maynever complete. For example, previously it was possible (given specificcircumstances) that a transaction (or critical section) would spin on alock variable infinitely. To illustrate, assume a counter is implementedas a lock variable, which is to indicate if any work has been done or ifa rendezvous has occurred in regards to a work queue. But in HLE a lockvariable is read as unlocked (i.e. global threads see the variable asunlocked) and then increment the lock internally (i.e. other threadsdon't see the lock as acquired to enable concurrent execution within thework queue). Yet, an HLE section may be waiting for the lock to be setto a number of threads testing it, so the critical section nevercompletes (i.e. it's still waiting on the counter to be incrementedglobally). Yet, with the implementation of timers, the critical sectiononly waits for the timeout period and then aborts, which may cause are-execution with traditional locks; this ensure forward progress forthe critical section/thread, instead of the thread spinning infinitelyon the counter/lock.

Consequently, any number of abort events (e.g. explicit abortinstructions, data conflicts, timer expirations, etc.) may be tracked;potentially at the direction of hardware, firmware, software, or acombination thereof. And furthermore, any of these entities mayseparately or together make a determination of whether an abort of aspeculative code region is to be performed based on the tracked abortevents, enabling robust, flexible, and intelligent abort controlmechanisms. Additionally, speculative code regions may include anycombination of speculative and non-speculative instructions, whichallows a programmer the upmost flexibility in utilizing TM and/or HLE.Moreover, hardware may provide software a mechanism to always abort aspeculative code region to support testing/debugging of an abortfallback path.

A module as used herein refers to any hardware, software, firmware, or acombination thereof. Often module boundaries that are illustrated asseparate commonly vary and potentially overlap. For example, a first anda second module may share hardware, software, firmware, or a combinationthereof, while potentially retaining some independent hardware,software, or firmware. In one embodiment, use of the term logic includeshardware, such as transistors, registers, or other hardware, such asprogrammable logic devices. However, in another embodiment, logic alsoincludes software or code integrated with hardware, such as firmware ormicro-code.

A value, as used herein, includes any known representation of a number,a state, a logical state, or a binary logical state. Often, the use oflogic levels, logic values, or logical values is also referred to as 1'sand 0's, which simply represents binary logic states. For example, a 1refers to a high logic level and 0 refers to a low logic level. In oneembodiment, a storage cell, such as a transistor or flash cell, may becapable of holding a single logical value or multiple logical values.However, other representations of values in computer systems have beenused. For example the decimal number ten may also be represented as abinary value of 1010 and a hexadecimal letter A. Therefore, a valueincludes any representation of information capable of being held in acomputer system.

Moreover, states may be represented by values or portions of values. Asan example, a first value, such as a logical one, may represent adefault or initial state, while a second value, such as a logical zero,may represent a non-default state. In addition, the terms reset and set,in one embodiment, refer to a default and an updated value or state,respectively. For example, a default value potentially includes a highlogical value, i.e. reset, while an updated value potentially includes alow logical value, i.e. set. Note that any combination of values may beutilized to represent any number of states.

The embodiments of methods, hardware, software, firmware or code setforth above may be implemented via instructions or code stored on amachine-accessible, machine readable, computer accessible, or computerreadable medium which are executable by a processing element. Anon-transitory machine-accessible/readable medium includes any mechanismthat provides (i.e., stores and/or transmits) information in a formreadable by a machine, such as a computer or electronic system. Forexample, a non-transitory machine-accessible medium includesrandom-access memory (RAM), such as static RAM (SRAM) or dynamic RAM(DRAM); ROM; magnetic or optical storage medium; flash memory devices;electrical storage devices; optical storage devices; acoustical storagedevices; other form of storage devices for holding information receivedfrom transitory (propagated) signals (e.g., carrier waves, infraredsignals, digital signals); etc, which are to be distinguished from thenon-transitory mediums that may receive information there from.

Reference throughout this specification to “one embodiment” or “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the present invention. Thus, theappearances of the phrases “in one embodiment” or “in an embodiment” invarious places throughout this specification are not necessarily allreferring to the same embodiment. Furthermore, the particular features,structures, or characteristics may be combined in any suitable manner inone or more embodiments.

In the foregoing specification, a detailed description has been givenwith reference to specific exemplary embodiments. It will, however, beevident that various modifications and changes may be made theretowithout departing from the broader spirit and scope of the invention asset forth in the appended claims. The specification and drawings are,accordingly, to be regarded in an illustrative sense rather than arestrictive sense. Furthermore, the foregoing use of embodiment andother exemplarily language does not necessarily refer to the sameembodiment or the same example, but may refer to different and distinctembodiments, as well as potentially the same embodiment.

What is claimed is:
 1. A system comprising: a plurality of cores, one ormore of the plurality of cores to concurrently execute multiple threads;one or more of the plurality of cores to perform out-of-order executionof instructions of the threads; one or more of the plurality of corescomprising: instruction fetch logic to fetch instructions of one or moreof the threads, instruction decode logic to decode the instructions,register renaming logic to rename one or more registers within aregister file, a data cache to cache data, a translation lookasidebuffer to store virtual to physical address translations, a second levelcache unit to cache instructions and data, and an execution unit toexecute a first instruction to indicate an end of the transactionexecution region and to cause memory transactions to be atomicallycommitted or aborted; and one or more integrated memory controllers tocommunicatively couple the plurality of cores to dynamic random accesssystem memory.
 2. The system as in claim 1 further comprising: aperipheral component interface express (PCIe) interface tocommunicatively couple the cores to one or more devices.
 3. The systemas in claim 1 further comprising: a shared cache to be shared by two ormore of the plurality of cores.
 4. The system as in claim 3 furthercomprising: a cache coherent interconnect to communicatively couple theshared cache to an accelerator device.
 5. The system as in claim 4,wherein the bus interface is cache coherent.
 6. The system as in claim 1further comprising: a peripheral component interface express (PCIe)interface to communicatively couple the cores to one or more devices; ashared cache to be shared by two or more of the plurality of cores; anda bus interface to communicatively couple the shared cache to anaccelerator device.
 7. The system as in claim 1, the execution unit tofurther execute: a second instruction to indicate a beginning of thetransactional execution region of instructions.
 8. The system as inclaim 1, the execution unit to further execute: a third instruction toabort transactional execution responsive to an abort condition.
 9. Thesystem as in claim 1, the execution unit to further execute: a secondinstruction to indicate a beginning of the transactional executionregion of instructions; and a third instruction to abort transactionalexecution responsive to an abort condition.